Application No.: 10/608,628 

Final Office Action dated: August 13, 2007 

Response to Final Office Action dated: December 13, 2007 

REMARKS 

In response to the Office Action dated August 13, 2007, Applicants 
hereby request reconsideration of the pending claims in light of the 
amendments above and the following remarks. 

STATUS OF CLAIMS 

Claims 1-22 as originally filed were pending. 
Claims 5, 6, and 10-22 are canceled. 
Claims 23-29 are newly added. 

Accordingly, claims 1-4, 7-9, and 23-29 are before the Examiner for 
consideration. 

CLAIM RETECTIONS 

In section 2 of the Office Action, claims 1-8, 10-18, and 20-22 were 
rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Pat. No. 
7,002,993 to Mohaban et al. ("Mohaban") in view of U.S. Application 
Publication No. 2003/0091017 to Davenport ("Davenport"). Claims 5, 6, 10- 
18, and 20-22 are canceled in favor of new claims 23-29. Applicants 
respectfully traverse the subject rejection in regards to claims 1-4, 7, and 8, 
since Mohaban and Davenport fail to show or suggest in combination all the 
elements of these claims as amended. 

A partial summary of the packet aggregation system of the present 
application can be found in Applicants 7 Response dated July 12, 2007. 

Turning first to independent claim 1, claim 1 has been amended to 
relate to an embodiment of the packet aggregation system summarized 
generally in sections 0010-0013 of the application. Here, the packet 
aggregation system is used in the context of transmitting time-delay 
intolerant information (also known as real-time information), which is 
information having one or more time strict time delay constraints. As 
explained in section 0004-0008 and 0022 of the application, for real-time 
packet data applications, an information stream (e.g., a digitized voice signal) 
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is converted into a stream of time-delay intolerant data packets, which are 
scheduled for transmission at a designated fixed rate depending on the time 
delay constraint(s) of the information in question. In a conventional system, 
the data packets are then periodically transmitted from a transmitter to a 
receiver at the fixed rate. This process is shown in the sketch below, for the 
case of an EVRC (Enhanced Variable Rate Codec) vocoder. 
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Here, the EVRC vocoder converts a voice /sound data signal into a stream of 
data packets, which are scheduled for transmission at a designated fixed rate 
of about one packet every 20 milliseconds. As indicated, a transmitter then 
transmits the data packets at the fixed rate, for reception at a receiver unit. 
Thus, a first packet is transmitted at time = 0 seconds, a second at time = +20 
milliseconds, a third at time = +40 milliseconds, and so on. The fixed rate of 1 
packet/ 20 msec is based on the time constraints of the voice data 
signal / information. For example, in a typical communication system it is 
necessary to transmit a voice data packet (containing 16-192 bits of 
information) every 20 milliseconds in order to adequately reproduce the 
original voice data signal at the receiver. (Transmitting packets at a lower 
rate may result in poor overall sound quality, breaks in sound, and the like.) 

The packet aggregation system of the present application is directed to 
data aggregation in this context, for aggregating time-delay intolerant 
information. Thus, as summarized in sections 0010-0013 of the application, 
time-delay intolerant data packets, which are scheduled for transmission at a 
designated rate, are generated as explained above, e.g., using a vocoder or 
other signal encoder. Then, however, instead of transmitting the data packets 
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at the designated rate, e.g., 1 packet every 20 msec, two or more of the time- 
delay intolerant data packets may be aggregated into an aggregated data 
packet, if channel conditions warrant, and based on other user service 
requirements and a negotiation between the transmitter and receiver. The 
aggregated data packet is then transmitted over the communication channel 
at a rate different than the designated rate of the original time-delay intolerant 
data packets. 
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An example of the system in operation is shown in the sketch above. 
Here, a stream of time-delay intolerant data packets (i.e., "real-time" data 
packets having strict time constraints), such as generated by a vocoder unit, is 
provided to an aggregator. Based on channel conditions of the 
communication channel over which the data is to be transmitted, and possibly 
on user service requirements such as overall system load, the data rate 
capability (e.g., bandwidth) of the system/ channel, and a QoS (quality of 
service) level assigned to the receiver, the transmitter negotiates with the 
receiver to determine an aggregation factor "N," which is the number of data 
packets to be aggregated into an aggregated data packet. If the system is in a 
state of heavy load, or if the channel conditions are poor, then it may be the 
case that N = 1, in which case no data packets are aggregated, and the original 
data packets are simply transmitted at the designated rate, as normal. If 
however the system is in a state of light load, or if channel conditions are 
particularly good, then N > 1 data packets are aggregated into an aggregated 
data packet, which can be transmitted at a rate other than the designated rate. 
As shown in the sketch above, for example, three data packets are aggregated 
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into a first aggregated data packet for transmission at time = 0, and three 
more data packets are aggregated into a second aggregated data packet for 
transmission at time = +10 msec. As should be appreciated, one goal of this 
method is to get more data packets to the receiver faster, when conditions 
warrant, than simply waiting for the data packets to be transmitted at the 
designated rate. Not only does the aggregation process improve 
communication efficiency generally, but if fewer data packets are transmitted 
at the fixed rate, then it is possible to add more users to the transmission 
queue, i.e., additional time slots are available for scheduling more users. 

As an example, one situation where this method / system is particularly 
advantageous is in a wireless network during an emergency or other heavy 
load period. At the onset of the emergency, say a major snowstorm, a number 
of mobile phone users may attempt to access the network at the same time, to 
contact family members, work, and emergency and other service providers. 
Since each user is generating real-time voice signals, which are scheduled for 
transmission at a fixed rate, in a conventional system the number of available 
time / data slots will quickly fill up. In other words, at each time point, the 
number of data packets scheduled for transmission may exceed the available 
transmission bandwidth. If this happens, some users may be denied service. 
In the packet aggregation system of the present application, however, channel 
conditions are monitored (in addition to other factors mentioned above) for 
determining if it is possible to aggregate time-delay intolerant data packets 
for a particular user. If so, "N" packets are aggregated into an aggregated 
data packet, as described above, which is transmitted at a different rate than 
the designated or fixed rate. In the sketch above for example, three data 
packets are aggregated into the first aggregated data packet, for transmission 
at time = 0. Thus, instead of the three data packets occupying three time slots, 
they occupy a single time slot. The other time slots can then be used to 
accommodate other users. 1 



The bandwidth used by one aggregated packet is greater than a single data packet, but less than if 
the multiple packets were transmitted separately. Plus, there are advantages in being able to 
accommodate more users due to the increase in available time slots for transmitting time-delay 
intolerant information. 
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It should be noted that in the context of aggregating time-delay 
intolerant information as described above, Applicants 7 packet aggregation 
system inherently works in the application layer of the communication 
system. (According to the standard TCP/IP model or Internet reference 
model, the application layer is the top network layer, which is used by most 
programs for network communication. Data is passed from the program in 
an application-specific format, then encapsulated into a transport layer 
protocol. Common application layer programs include file transfer and 
management protocols, directory services, and communication 
services/ protocols such as HTTP. Below the application layer are the 
transport layer, the network layer, the data link layer, and the physical layer.) 
Thus, aggregation of time-delay intolerant data packets is carried out as an 
application process, e.g., vocoder voice signal conversion and transmission. 
Because packets are aggregated at the application layer, it inherently follows 
that the aggregated data packets will be further processed according to the 
communication system's protocols at the lower layers of system functionally. 
In the packet aggregation system of the present application, which operates in 
the context of a packet data communication system / network, therefore, an 
aggregated data packet may be re-divided into packets, at the transport layer, 
for transmission over the communication channel of interest. The 
transmission packets do not correspond to the original time-delay intolerant 
data packets. Instead, they are formatted according to the network's 
transport layer protocols, just as if the aggregated data packet was "one big" 
time-delay intolerant data packet. As should be appreciated, therefore, for 
aggregating time-delay intolerant data packets, the real-time packet 
aggregation system of the present application works above and separately 
from transmission packet generation and aggregation at the transport layer, 
i.e., the transport layer may perform its own packet aggregation, but of 
transmission packets, not of time-delay intolerant data packets. This 
difference is illustrated in the sketch below. 
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Claim 1 is directed to a transmitting communication equipment used 
in a system as described above, for aggregating time-delay intolerant 
information. Claim 1 includes the following elements (paraphrased): 

• An aggregator for aggregating information and for transmitting 
the aggregated information as an aggregated packet to a 
receiving communication equipment. 

• The information comprises a plurality of time-delay intolerant 
data packets scheduled for transmission at a designated rate. 
The designated rate is based on at least one time delay 
constraint of the data packets. 

• An aggregation factor, which is the number of data packets 
included in the aggregated packet, is based at least in part on (i) 
one or more user service requirements and (ii) a negotiation 
between the transmitting communication equipment and the 
receiving communication equipment. 

• The aggregated packet is transmitted by the transmitting 
equipment to the receiving equipment at a rate different than 
the designated rate of the data packets. 



None of the references of record, alone or in combination, show all of these 
elements. More specifically, neither Mohaban nor Davenport show a system 
where time-delay intolerant data packets are aggregated into an aggregated 
data packet, where the size of the aggregated packet is negotiated between 
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the transmitter and receiver and based on user service requirements, and 
where the aggregated packet is transmitted at a rate different than the 
scheduled transmission of the time-delay intolerant data packets. 

As explained in the previous Response, Mohaban relates to 
aggregating media data packets from different phone calls or other 
transmissions, for improving bandwidth efficiency. Aggregated data packets 
are generated using compressed RTP (real-time transport protocol) segments 
and a set of ID codes (e.g., a trunk ID and session context ID) to identify the 
individual data packets in the aggregated packet. See Mohaban at col. 3, lines 
34-49. Considering that RTP is a transport layer mechanism (in the TCP/IP 
model), and in light of the explanation above, the system in Mohaban can be 
thought of as a transport layer aggregation method, i.e., Mohaban involves 
modifying an existing transport layer mechanism to improve bandwidth 
efficiency. 2 Generation of the aggregated packets is a standalone operation, 
and does not involve considerations of user service requirements or a 
negotiation between the transmitting and receiving equipment. Moreover, 
there is no mention in Mohaban of aggregating time-delay intolerant data 
packets into an aggregated data packet, which is then transmitted at a 
different rate than the scheduled transmission rate of the time-delay 
intolerant data packets. 

The Davenport reference fails to rehabilitate the deficiencies of 
Mohaban. In particular, in the Office Action at page 4, the Examiner agreed 
that Mohaban does not teach basing the size of an aggregated data packet on 
a negotiation between the transmitting and receiving communication 
equipment, but went on to opine that Davenport teaches basing the size of a 
packet on such a negotiation. Applicants agree that Davenport discloses 
adjusting packet size, and that "the quality of the communication link . . . may 
be considered to determine the optimal packet size." See Davenport at 



2 More specifically, Mohaban is concerned with the application layer, but achieves 
aggregation by modifying the underlying IP/transport layer through introduction of a 
custom header. Compression may be included as well. 
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section 0019. 3 However, there is no explicit teaching in Davenport of a 
negotiation between the transmitting and receiving equipment. Moreover, to 
the extent Davenport suggests such an operation, it is important to note that 
Davenport does not relate to packet aggregation in the first place. Instead, in 
Davenport a "chunk" of data is broken into packets, the size of which may be 
adjusted based on the quality of the communication link; there is no mention 
or suggestion in Davenport of aggregating data packets. As such, even if 
"Davenport teaches a size of the packet is based at least in part on a 
negotiation between the transmitting communication equipment and the 
receiving communication equipment," as stated by the Examiner, Davenport 
does not teach basing the size of an aggregated packet on such a negotiation, 
where the size is a direct function of the number of data packets included in 
the aggregated packet. Put another way, to the extent Davenport suggests a 
transmitter / receiver negotiation, this would be used to determine how to 
divide a larger data block into smaller packets. Applicants 7 packet 
aggregation system, on the other hand, relates to basing the number of 
smaller packets in a larger, aggregated packet on a transmitter / receiver 
negotiation. The two processes are not interchangeable, and a disclosure of 
using a transmitter /receiver negotiation as a factor in one system does not 
translate as a teaching applicable to the other system. The same is true in 
regards to communication channel conditions - the teaching in Davenport of 
basing packet size on communication link quality is different from basing the 
size of an aggregated packet (e.g., the number of data packets in the 
aggregated packet) on communication link quality, as in Applicants 7 system. 

In the Office Action, the Examiner states that Davenport explicitly 
teaches determining the size of an aggregated data packet through a 
transmitter/ receiver negotiation. See, e.g., Office Action at page 8. 
Applicants respectfully disagree. Instead, Davenport teaches that optimal 
packet size may be determined using communication link quality, when 
dividing bulk transfer data into packets for transmission. See, e.g., Davenport 

3 Based on Applicants' review and understanding of Davenport, it appears that the 
packet generation process disclosed in Davenport is of the type typically used in 
communication networks, e.g., packet size is based on communication channel 
conditions, which is a known, standard process. 
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at sections 0018-0019 ("Once communication has been initiated 48 between 
the mobile asset and a fixed location via a communication link, the size of the 
data packets used to download the data may be selected, as is known in the 
art of digital communications/ 7 ) Dividing data into packets for transmission 
is not the same as aggregating data packets into an aggregated data packet. 

To the extent the use of the term "packet size" in claim 1 could be 
construed in a manner for falling within the ambit of Davenport, claim 1 has 
been amended to recite that that aggregation factor, which is the number of 
data packets included in the aggregated packet, is based on a negotiation 
between transmitter and receiver. Since the system in Davenport does not 
utilize or otherwise relate to packet aggregation (indeed, quite the opposite), 
it cannot reasonably be said that Davenport teaches basing an aggregation 
factor on a transmitter/ receiver negotiation. 

Further evidence that Davenport is far removed from the packet 
aggregation system of the present application can be found by taking note of 
the type of data transferred in Davenport. In particular, Davenport relates to 
bulk data transfer, for obtaining systems or operational data from a train or 
other moving vehicle. See Davenport at sections 0003, 0012, 0017, etc., where 
it is noted that (i) the system in Davenport is unrelated to voice (i.e., real-time) 
data transfer, and is instead related to bulk data transfer, and (ii) data transfer 
is typically scheduled in advance. Thus, even if Davenport taught packet 
aggregation, and the idea of basing the number of bulk transmission data 
packets in an aggregated packet on channel conditions and /or a 
transmitter/ receiver negotiation (which is not the case), then there would still 
be no teaching or suggestion of aggregating time-delay intolerant data 
packets into an aggregated data packet, or of basing the number of time-delay 
intolerant data packets in the aggregated packet on channel conditions 
and /or a transmitter/ receiver negotiation, in a real-time application. 

On a side note, in the instances where Davenport mentions "real-time" 
processes (see, e.g., Davenport at section 0023), this relates to real-time 
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measurements of channel conditions, not to the processing of real-time packet 
or other data. 

In light of the above, it is respectfully submitted that Mohaban and 
Davenport in combination fail to disclose all the elements of claim 1 as 
amended. Accordingly, claim 1 is believed allowable. Claims 2-4 and 7-9, 
which depend from claim 1, are believed allowable as depending from an 
allowable base claim, and for reciting additional elements neither shown nor 
suggested in Davenport and Mohaban. For example: 

• Claim 2 recites that the aggregation factor (i.e., the number of time- 
delay intolerant data packets in the aggregated data packet) is based on 
" channel conditions of a communication channel used for transmitting 
the aggregated packet between the transmitting communication 
equipment and the receiving communication equipment. " Mohaban 
relates to aggregating unrelated packets by modifying the RTP codec, 
and does not teach aggregating packets based on channel conditions. 
As discussed above, Davenport teaches basing packet size on channel 
conditions (in the context of dividing bulk data into packets), but does 
not disclose generating aggregated packets, or basing the number of 
packets in an aggregated packet on channel conditions. 

• Claim 3 is further allowable for reasons similar to those set forth 
immediately above in regards to claim 2. 

• In regards to claim 4, neither Davenport nor Mohaban relate to 
transmitting or otherwise processing time-delay intolerant data 
packets, scheduled for transmission at a designated rate, at a rate other 
than the designated rate. 

• Claim 7 recites that the aggregation factor is further based on user 
service requirements that include "(i) a data rate capability of a 
communication system within which the equipment is being used, (ii) 
a current loading level of the system and / or channel, and (iii) a 
designated quality of service level of the receiving communication 
equipment in the system/' (The latter factor is described in section 
0026 of the application.) Davenport discloses using channel conditions 
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in an unrelated context, but neither Davenport nor Mohaban disclose 
basing an aggregation factor on such user service requirements. 

In section 3 of the Office Action, claims 9 and 19 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Mohaban in view of Davenport 
and further in view of U.S. Pat. No. 6,839,356 to Barany et al. Claim 19 is 
canceled. Claim 9 is believed allowable as depending from an allowable base 
claim, since Mohaban and Davenport in combination fail to show all the 
elements of the claims from which claim 9 depends. 

To the extent any grounds for rejection were not explicitly addressed 
herein, they are believed moot in light of the claim amendments above. 

NEW CLAIMS 

Newly entered claims 23-29 are believed allowable for reasons similar to 
those set forth above in regards to claims 1-4, 7, and 8. New claims 25 and 29 
recite elements inherent to the disclosure of the application, as discussed 
above. Applicants aver that no new matter is entered. 
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CONCLUSION 

In view of the foregoing, it is respectfully submitted that pending 
claims 1-4, 7-9, and 23-29 are in condition for allowance, and action to that 
effect is earnestly solicited. 

Pursuant to 37 C.F.R. § 1.136, Applicants hereby petition for a one- 
month of extension of time for response, thereby extending the period for 
response to and through December 13, 2007. Authorization is hereby given to 
charge any fees owed to our Deposit Account No. 13-0235. 

Respectfully submitted, 



By / Tohn A. Kramer / 

John A. Kramer 
Registration No: 46,302 
Attorney for Applicants 



Mccormick, paulding & huber llp 

CityPlace II 
185 Asylum Street 
Hartford, CT 06103-3402 
(860) 549-5290 
Customer No.: 51094 
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